A Content Distribution Network (CDN) (also referred to in the literature as a “Content Delivery Network”) is a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance. CDNs serve a large fraction of the content available on the Internet today. Such content includes, for example, web objects (e.g., text, graphics, scripts, and the like), downloadable objects (e.g., media files, data files, software, documents, and the like), applications (e.g., e-commerce, web portals, and the like), live streaming media, on-demand streaming media, content associated with social networks, and the like.
FIG. 1 illustrates a content delivery system 12 employing a CDN 14. The content may be delivered to a content subscriber 16 (e.g., a cable subscriber, a client of a broadband service provider or a telephone company, and the like) via a delivery platform 18. The content may be multimedia content. The term “multimedia content,” as used herein, may include, for example, data content having audio-visual segments, audio-only components, video-only components, other non-audiovisual components (such as, for example, plain data, game data and other executables, supercollider data, and the like), or a combination of one or more of these segments/components. In the discussion herein, the terms “multimedia content” and “content” may be used interchangeably.
Traditionally, audio-visual or other multimedia services offered or provided by telephone companies and cable operators have been distributed over managed access lines where the bandwidth required for a good quality of experience has been provisioned and is suitably robust. However, there are now many types of Internet-connected devices that are capable of high quality audio/video playback. These include, for example, smart TVs, gaming consoles, PCs, laptops, tablets, smartphones, Blu-Ray™ devices, and the like. Hence, multimedia content providers such as media companies and e-commerce vendors are increasingly making their content available directly on the Internet via third-party services such as Hulu™ or Netflix™. These third-party services, in turn, use/deploy CDNs to deliver this received content (indicated by arrow 20 in FIG. 1) to the end-user 16. The content providers pay these third-party services (which may be owners or operators CDNs) for delivering the provider's content to the corresponding audience of end-users. The CDN 14 may use the delivery platform 18, which may include, for example, a portion of the Internet, an Internet Service Provider's (ISP) network, a cable or television service provider's network (in which case the content may be said to be delivered “Over-The-Top” (OTT) of an operator's network), and the like. The CDN operator or owner may pay ISPs, carriers, and network operators for hosting its servers in their data centers (not shown) to facilitate delivery of the content 20. Besides better performance and availability, CDNs also offload the traffic served directly from the content provider's origin infrastructure, resulting in cost savings for the content provider. In addition, CDNs provide the content provider a degree of protection from Denial of Service (DoS) attacks by using their large distributed server infrastructure to absorb the attack traffic.
A CDN may be comprised of various “nodes” that transmit and cache multimedia content as is appropriate. In FIG. 1, such “nodes” are identified by reference numerals 22 through 31. Some of the nodes may function as regional server nodes (e.g., nodes 23-25 in FIG. 1), some others may function as edge nodes (e.g., nodes 26-31 in FIG. 1), whereas there may be at least one node in the CDN 14 functioning as an origin server (e.g., the origin server 22 in FIG. 1) that is the primary recipient of the content 20 input to the CDN 14 and may be responsible for the received content's subsequent distribution to appropriate regional/edge nodes. The content is then transmitted from the appropriate node to the end user 16. Various pieces of content are stored, e.g., by the origin server 22, in various (sometimes redundant) nodes in the CDN. For example, content that is more popular (i.e., requested more often) may be pushed to the edge nodes 26-31 at a local level, while less popular content may be stored in the regional nodes 23-25 at a regional level, and still less popular content may be stored at a “higher” node in the hierarchy—e.g., at the origin server 22 itself. Content sent to an edge node is meant to be retrieved by end users physically close to that node. It is possible that two users (even in the same household or location) may retrieve the same content from two completely different node servers.
Adaptive Bit Rate (ABR) streaming is a technique used in streaming multimedia content over computer networks. ABR may be used to deliver content over the combination of the CDN 14 and the delivery platform/network 18. Adaptive streaming technologies are primarily based on Hypertext Transfer Protocol (HTTP) and designed to work efficiently over large distributed HTTP networks, such as the Internet. Thus, in the discussion below, the terms “streamed” or “adaptively-streamed” or “ABR-streamed” (or terms of similar import) may be used interchangeably to refer to a multimedia content delivered through adaptive streaming, which may include ABR HTTP downloads or any other similar network-based content delivery method.
In ABR streaming, a user device's bandwidth and processing capacity are detected in real time, and the quality of multimedia stream is adjusted accordingly. The source audio-visual content is encoded at multiple bitrates, and then each of the different bitrate streams is segmented into small multi-second (e.g., 2 to 10 seconds) parts. A manifest file is provided to the streaming client. The manifest file makes the client device aware of the available streams at different bitrates, and segments of the streams. The player client can thus switch between streaming the different encodings depending on available network resources. For example, when the network throughput has deteriorated, the client device may find that the download speed for a currently-downloaded segment is lower than the bitrate specified for that segment in the manifest file. In that event, the client device may request that the next segment be at that lower bitrate. Similarly, if the client finds that the download speed of the currently-downloaded segment is greater than the manifest file-specified bitrate of the segment downloaded, then the client may request that next segments be at that higher bitrate.
Some examples of ABR streaming solutions include the MPEG-DASH standard (where “MPEG” refers to Moving Picture Experts Group and “DASH” refers to Dynamic Adaptive Streaming over HTTP), the HTTP Live Streaming (HLS) solution offered by Apple, Inc. for iPhones and iPads, and the Smooth Streaming solution offered by Microsoft, Inc.
As noted earlier, in adaptive streaming, multiple versions of a video/audio-visual content are offered at different bitrates or quality levels (e.g., from 100 Kbps (kilo bits per second) to 2 Mbps (mega bits per second)). Thus, for example, video is transported not as one big file, but as separate, distinct chunks (e.g., by “cutting” up the video in small files), and user-agents are allowed to seamlessly switch between quality levels specified in a manifest file (e.g., based upon changing device or network conditions), simply by downloading the next chunk from a different bitrate level.
Thus, in ABR streaming, videos (or audio-visual data) are served as separate, small chunks, and the accompanying manifest file provides metadata needed for the client's ABR player. The manifest file may be an Extensible Markup Language (XML) file. The media server that provides the ABR streaming may automatically adapt to any changes in each user's network and playback conditions. A user agent (in the client's ABR player) may parse the manifest file to appropriately switch between different stream levels (or bitrates). The ABR mode of content delivery is useful in many applications such as, for example, long downloads of video content (where ABR streaming may save bandwidth if the user is not currently watching the video), live video feeds (where ABR streaming may maintain the stability of the content delivery), delivery to mobile devices (where lots of buffering may be needed due to changing network conditions). Adaptive streaming technologies thus allow client devices to adjust or adapt to changes in bandwidth by switching between higher and lower quality video segments indicated within a manifest file.